最近，我花了一個月時間閱讀了一本書《Implementing Domain Driven Design》（簡稱IDDD）。由於封面是紅色，因此在DDD社群中，也有人稱為 “小紅書”。
原本打算寫書摘，但看了這系列的 鐵人賽文章 後，發現內容寫得非常好，甚至結合了c lean architecture 的概念。我認為自己很難寫得比他更好，因此決定只紀錄自己的關鍵收穫和心得。
Ubiquitous language(通用語言)
DDD非常強調在團隊內使用通用語言溝通，這樣能避免 “每次工程師講話都聽不懂” 的情況，還能讓程式碼更貼近業務邏輯。最理想的情況下，團隊成員甚至能大致看懂程式碼的目的。
Domain / Bounded Context
Domain 和 Bounded Context 是書中的核心概念。Domain 即公司業務範圍，我們可以將這些業務拆分成多個 subdomain，而軟體就是要解決這些 subdomain 中在等待軟體解決的問題。我們會通過 bounded context 作為系統邊界設計多個系統，每個系統可能對應一個 subdomain，或同時解決多個 subdomain 的部分問題。
這部分的設計屬於戰略設計（Strategic Design），也就是設計大架構和方向。
建模工具
DDD 提供了各種建模工具，並明確定義它們的職責，包括：Entity / Value Object / Repository / Aggregate / Application Service / Domain Service / Domain Event。
這部分的設計屬於戰術設計（Tactical Design），也就是實際開始寫程式。
Event Driven & CQRS
書中用 shell script 的命令範例來講解事件驅動的概念，讓我耳目一新並更加理解了事件驅動架構（Event Driven Architecture, EDA）。另外，書中提到，由於 Event Sourcing 系統難以從資料庫查詢所有需要顯示的數據，因此非常適合搭配 CQRS 來分離 Query Model 和 Command，這點也讓我有種豁然開朗的感覺。
心得
看完書的這幾天，不論是寫程式還是思考問題時，我彷彿被洗腦一般，都會忍不住用DDD的思維去思考，這代表我學到了很多東西吧！
雖然目前使用的 Rails 框架預設使用方式中，資料模型和領域模型被綁在一起，這部分若要效法 DDD，會需要額外花心力拆解。但其他如 value object 和分層結構的概念仍有很多可以應用。
同時，這本書詳細介紹了 Event Sourcing，我也因此查詢了 Event Driven Archiecture 中的各種不同類型，收穫非常豐富。
我相信很多人跟我一樣，在看完這本書後，對書中的概念仍有些模糊。因此我有額外與看過這本書的同事們進行交流討論，並參考了其他好心工程師在網路上分享的文章，才覺得自己對書中要傳達的知識有了更好的掌握。在此也特別感謝他們！
